The present invention relates generally to mobile computing devices, and more specifically, to a mobile hub and techniques for managing events in a mobile hub.
The concept of personal mobile gateways or personal mobile hubs revolves around the concept of a mobile device typically having a central processing unit CPU, a random access memory RAM, a non volatile (NV) storage, an interface to a local wireless network technology (e.g., Bluetooth) and/or an interface to a wireless wide area network technology (e.g., GSM/GPRS).
An attractive application area of mobile hubs is the health care/medical/pharmaceutical application area where sensor and actuator devices connect via, for example, Bluetooth to the mobile hub. Each sensor periodically transmits a sensor value to the mobile hub or is polled by an adapter running on the mobile hub. Actuator devices similarly receive instructions from the mobile hub device from time to time by polling the mobile hub or by being connected by an adapter running on the mobile hub. On the mobile hub the sensor data needs to be analyzed, perhaps correlated to data of other sensor devices, and might also be relayed to network based services. Typically, the data is of a discrete nature, and each sensor value can be treated as an event. Thus, each sensor submits a sequence of events via the wireless communication link to the mobile hub. Likewise, mobile hub internal processes can generate events. Of course, it might be necessary to make these internally created events or the events received from external devices available to consumers on the mobile hub and/or even mobile hub external services. Thus, for handling events and distribute them the right way, the mobile hub needs an event engine, also called event manager.
Event systems as such have been known for quite some time now. There are synchronous event systems and asynchronous event systems. In synchronous event systems, events are propagated along a hierarchical path from the leaves up to the root. Each entity operates on a received event in turn.
One of the best-known examples of asynchronous event systems is the Linda Tuplespace system or IBM's T-Spaces. There, events are posted to a central “blackboard”, which is implemented as a database, by event sources. Event consumers then search through the blackboard specifying patterns or search expressions for the tuples they are interested in.
The main advantage of synchronous event systems is that each registered entity (entities have to register) is guaranteed to be called once. At the end of the invocation chain one knows for sure that a certain event has been dealt with. Also, the synchronous event system by definition imposes a certain order in which registered events are called: By using appropriate return values, it is possible to influence delivery of events to entities later in the processing chain. This advantage of the synchronous model is at the same time its biggest disadvantage: Input/Output (I/O) operations, for example, can take a long time to complete. An entity whose event handler is invoked and initiates an I/O operation as part of the event handler might consequently become blocked and, thus, block the whole synchronous event system. Also, the event handling entity might become blocked before being invoked, and thus, can also block the event system.
Asynchronous event systems do not suffer from this particular problem: Here, all event listeners are either informed on the new event simultaneously or interested entities regularly poll the event system for newly arrived events themselves. On the other hand, with asynchronous event systems it is rather difficult to state event closure, i.e. that all entities have seen the event, and almost impossible to enforce an order. Also, with tuple/blackboard based systems, there is a problem of having to support a database and of having to do garbage collection on the posted events.
Hence, asynchronous event systems can be characterized as soup model or pond model. Events are dumped into a global soup or pond. Event subscribers then search the soup/pond. Likewise, synchronous event systems can be characterized as a flash model. An event is flashed to all subscribed entities.
Mobile devices such as mobile hubs, that can for example be a mobile phone platform with a wireless wide area network component (WWAN, e.g., GPRS), a wireless local area network component (WLAN, e.g., Bluetooth), and a CPU with local volatile and non-volatile storage, are characterized by their hub nature. External entities such as sensors, devices or appliances connect via the WLAN to the mobile hub and provide data to software components running on the hub. These or other software components process the received data in some way and then provide data via the WWAN to services running somewhere in the Internet.
Synchronous event systems are unsuitable to perform the processes required for a mobile hub due to the inherent I/O operations that have to be carried out. Asynchronous event systems on the other hand are not particular useful either, as they require a database system to be maintained on the mobile device itself. Such a database would require a lot of resources on a mobile device that typically is characterized by providing scarce resources due to its portable properties.